-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make functions a compile time construct on @strict
#2789
Conversation
<--- Didn't read the first section of this PR I think as a useful median between first class functions, functions names/signatures should be able to be overwritten. That shouldn't be a problem in a future where you could do # library.txt
function void table:myLibraryFunc() {
error("This is a stub! Define it in your code!")
}
.........
# file.txt
#include library.txt
function void table:myLibraryFunc() {
print(This)
} e.g., I wanted to create a library in E2 that works best with function references but to do so would require disabling |
Either the library should define table:myLibraryFunc() or the function should be taken as a callback to another function. |
Actually, maybe a better solution, if you could add UDFs to |
Yeah, which would require removing overriding / "runtime" functions. I'm ofc open to that even if I think #ifdef should probably be scrapped in favor of a more general |
Should be merged after #2829 for the people currently using stringcalls and |
No overriding
Overriding functions at runtime is no longer a thing on
@strict
. It's rare, odd dynamic behavior that shouldn't really be a thing. Function objects will fulfill their purpose in the future.It gives a warning without
@strict
for backwards compatibility.Compile time
Like events, functions on
@strict
will now be compile time constructs, so it doesn't matter if they're inside anevent tick() {}
loop or something. The function will just be created once when the chip is compiled.Basically: they will be cheaper to call and create. I raised the cost of calling functions on non-
@strict
, but the base cost is still 10 ops (will likely be lowered in the future).Breaking Change to String Calls
Since they will be compile time constructs, string calls to userfunctions won't work on
@strict
(will get a "no such function" error). This could be reverted while keeping the perf boost from calling, but the cost of creating the function will still exist.I think it is a worthwhile break since stringcalls should hopefully be made obsolete soon with function objects.